完整程式碼可在 GitHub 專案中找到：Finetune-30-days-demo / day-17

在 Day 16，我們完成了 JWT + RBAC，讓平台具備了「誰可以做什麼」的基礎能力。
但在多人使用的情境裡，光有權限控制還不夠，我們還需要知道 「誰做了什麼、何時做的、結果如何」 —— 這就是 Audit Log 的價值。

為什麼需要 Audit Log？

想像這些場景：

• 管理員收到投訴：「我昨天明明提交了任務，怎麼沒有結果？」
• 系統突然出現異常，需要追查是誰呼叫了什麼 API 導致問題。
• 多租戶情境下，必須要能稽核不同使用者的操作，確保資源使用合理。

Audit Log 的角色不是強化功能，而是讓系統 可追溯、可稽核、可調試。這代表平台從「能運作」走向「能管理」。

MVP 設計與實作

這次我建立了一個 最小可用的 Audit Log 子系統，包含紀錄與查詢兩部分。

1. Audit Log 模組

   • 初始化資料表
   • 攔截 API 請求並自動寫入紀錄
   • 提供 save_audit_log() 與 get_audit_logs() 函式

2. FastAPI Middleware

   • 在主程式載入 AuditLogMiddleware
   • 所有請求都會被攔截並保存，包括 user_id、role、method、path、status_code

3. 查詢 API

   • 新增 /audit/logs 端點

   • 支援篩選條件：

     • user_id（查詢特定使用者）
     • role（區分 admin/user）
     • start_time, end_time（依時間範圍篩選）
     • limit（限制回傳筆數）

範例輸出：

[
  {
    "user_id": "admin",
    "role": "admin",
    "method": "GET",
    "path": "/tasks",
    "status_code": 200,
    "timestamp": "2025-09-20 21:30:01"
  },
  {
    "user_id": "user123",
    "role": "user",
    "method": "POST",
    "path": "/train",
    "status_code": 200,
    "timestamp": "2025-09-20 21:31:45"
  }
]

落地效益與未來優化方向

落地效益

• 提升系統可追溯性，讓每個操作都有來源可查。
• 搭配 Day 16 的 RBAC，能進一步區分不同角色的操作行為。
• 查詢 API 提供了基本篩選能力，方便管理員快速檢索特定使用者或時間段的操作紀錄。
• 為後續的多租戶與監控模組鋪下基礎。

未來優化方向

• 目前查詢 API 還是「基礎版」，沒有分頁與排序功能。
• 長期紀錄會膨脹，需要搭配儲存策略（例如定期壓縮或轉移到專用日誌系統）。

Audit Log 雖然不會讓模型更快或更準，但它讓平台 真正具備了產品級的可追溯性。
使用者的操作有跡可循，異常情況能夠調查，管理員也能透過 API 快速查詢與稽核。這一步不僅讓系統更透明，也讓多人協作變得更安全、更有秩序。

未來，當我們進一步整合多租戶設計與資源治理時，Audit Log 將不只是「輔助功能」，而會成為系統可靠性與透明度的核心支柱。

📎 AI 協作記錄：今日開發指令

1. 新增 Audit Log 模組
 功能：
 - init_audit_table()
 - save_audit_log(user_id, role, method, path, status_code)
 - AuditLogMiddleware
 - get_audit_logs(...)

 2. 在 FastAPI 主程式載入 Middleware
 修改內容：
 - 匯入並註冊 AuditLogMiddleware
 - 確保所有請求都會被攔截並寫入紀錄

 3. 新增查詢 API
 功能：
 - 新增 /audit/logs 端點
 - 支援條件篩選：user_id、role、start_time、end_time、limit